Процессная архитектура и владельцы
Операционное совершенство · у кого какой процесс, когда пересматривался регламент и насколько исполнение расходится с ним
| Вариант исполнения | Доля | Расхождение с регламентом | Что это значит |
|---|---|---|---|
| Регламентный: заказ → резерв → наряд → выработка → закрытие | 86,1 % | — | совпадает |
| Наряд выдан до подтверждения обеспеченности | 8,4 % | пропущен шаг резервирования | нарушение R-MES2 |
| Повторное открытие закрытого заказа | 3,7 % | переход вне статусной модели | вход для пересмотра |
| Закрытие без подтверждения последней операции | 1,8 % | пропущен шаг выработки | нарушение R-MES16 |
| Итого восстановлено исполнений | 100 % | за 90 дней | process mining |
Контракт экрана (для ТЗ)
Объект / архетип
Объект доступа не назван, и это не пропуск. В книге объекты OBJ-* заведены только для НСИ и администрирования; у модуля OPX их нет. Придумать код здесь значило бы завести первоисточник в потребителе (П1.1) — заводит TMOD-32. Запись — ЗАП-OPX-01 «Процесс предприятия», одиннадцать полей, статусная модель на семь переходов. Архетипы — tree-card (репозиторий L1—L4 слева, карточка процесса справа), dashboard (свод управляемости, ради которого экран заведён) и document (карточка процесса: шапка полей и табличная часть с вариантами исполнения).
Поля
Взяты из §6 постановки Спецификация_Процессная_архитектура.md, типы — каноническими написаниями словаря (check_tipy_poley.py).
| Поле | Тип | Обязательное | Правило |
|---|---|---|---|
| Наименование процесса | текст | да | R-OPX5 |
| Уровень архитектуры L1—L4 | перечисление | да | R-OPX5 |
| Владелец процесса | ссылка | да | R-OPX1: роль либо должность, не человек |
| Регламент процесса | ссылка | да для состояния «Регламентирован» | R-OPX2 |
| Норматив пересмотра, месяцев | число | да | R-OPX2 |
| Дата последнего пересмотра | дата | да | R-OPX2: по истечении — «Регламент устарел» |
| Целевое значение КПЭ | число | да с уровня A3 | — |
| Фактическое значение КПЭ | число | да с уровня A3 | — |
| Доля исполнений по регламентному варианту | число | считает система из журналов | R-OPX3 |
| Открытое улучшение | ссылка | да при КПЭ ниже целевого | цель OPX-2 |
| Процесс-приёмник при выводе | ссылка | да при выводе из архитектуры | R-OPX4 |
Состояния экрана
Пусто · загрузка · ошибка · нет прав · данных больше предела — показаны блоком выше дословно по §4 постановки. Состояние «Ошибка» помечает долю исполнений «неизвестно», а не нулём: ноль здесь читался бы как «регламент не соблюдают».
Права (кнопка ↔ операция)
| Действие | Операция | Роли |
|---|---|---|
| Внести процесс в репозиторий, описать модель | C | OPX.OPER, OPX.ADMIN |
| Назначить владельца процесса | APPR | OPX.APPR |
| Утвердить регламент и норматив пересмотра | APPR | OPX.APPR |
| Вывести процесс из архитектуры со ссылкой на приёмник | POST | OPX.APPR |
| Выгрузить отчёт о полноте архитектуры и соблюдении | EXP | OPX.READ и выше |
Чего здесь намеренно нет
Разрыва между целевым и фактическим показателем и работы с улучшениями (OPX-2), потерь в потоке и выравнивания (OPX-3) — это соседние цели со своими экранами. Моделирование в нотации BPMN живёт своей формой: экран показывает наличие и состояние модели, а не редактирует её. Смешение дало бы редактор схем, на котором нельзя ответить, сколько процессов без владельца.
Связанные термины и уровень зрелости
Процесс предприятия · владелец процесса · регламент · норматив пересмотра · вариант исполнения — показывается с уровня A2 / B2, ниже прочих экранов прохода. Это осознанно: владелец и регламент нужны раньше, чем показатели и статистический контроль. На A2 экран работает без КПЭ и доли исполнений — они появляются с A3.